Computer networks often employ encryption techniques for security against unwanted dissemination of information and malicious interception or corruption of data transported thereby. Encryption involves performing a predetermined mathematical computation on the data to render it unintelligible prior to transmission, yielding a so-called ciphertext form, and performing an inverse computation at a receiving end to recover the original data in a so-called plaintext form. Therefore, encryption typically imposes a handshaking or setup exchange to identify the encryption and corresponding inverse (decryption) functions and/or operations. One typical encryption setup is a public key exchange, as is known to those of skill in the art.
Conventional protocols embed provisions for such encrypted exchanges into the protocol. For example, the TCP/IP protocol employs a secure socket layer (SSL) adapted to support encrypted transmissions. Typical TCP/IP transmissions employ a system of well known ports for identifying types of data traffic transported. Such well known ports identify common types of traffic to facilitate interpretation by sending and receiving entities, and are described in IETF RFC 1700, “Assigned Numbers”). For example, a conventional web page request, employing the Hypertext Transfer Protocol (HTTP), employs port 80. Conversely, as indicated above, an encrypted web page request using SSL mechanisms employs a Secure Hypertext Transfer Protocol (HTTPS), utilizing well-known port 443.
Sending and receiving entities exchanging encrypted message traffic must nonetheless participate in a setup exchange to coordinate usage of conventional encryption parameters. However, many users are unfamiliar or uninterested with the conventional setup and exchange procedures, as such so-called key exchanges tend to be technically robust. Further, performance and staleness issues tend to complicate the exchange by imposing timely updates and/or regeneration of key variables, and burdening transmission performance with the increased processing required for greater security. In general, the seamlessness or transparency of the encryption mechanism tends to be inversely proportional to the degree of security thereby provided.